AWS 네트워크 구조와 VPC, Subnet을 CIDR로 할당받기

AWS의 네트워크 분리 구조

AWS는 전 세계 수백만 명의 사용자가 동시에 서비스를 이용할 수 있도록 설계된 거대한 인프라 플랫폼이다. 이 거대한 트래픽과 데이터를 안정적이고 빠르게 처리하기 위해, AWS는 네트워크를 계층적으로 분리해 놓았다.

VPC와 Subnet 그리고 CIDR을 알기 전에, Region과 AZ에 대해서 알아보자

Region 과 Availability Zone

AWS의 가장 큰 단위는 리전(Region) 이다. Region은 실제 물리적인 데이터센터들이 모여 있는 하나의 지역 단위이며, 각 리전은 서로 완전히 독립된 인프라로 운영된다. 예를 들어, 한국 유저는 “서울 리전(ap-northeast-2)”을 이용하게 되는데, 이 리전은 물리적으로 한국 땅에 존재하는 AWS의 데이터센터(AZ) 묶음 이다.

한 리전 내부에는 여러 개의 데이터센터인 가용 영역(AZ, Availability Zone) 이 존재한다. 예를 들어, 서울 리전에는 ap-northeast-2a, 2b, 2c 같은 AZ가 있다.

Region은 왜 필요할까

  • 유저들이 네트워크를 사용할 때 물리적으로 가까운 곳에서 응답할 수 있도록 만들기 위해
  • 어떤 나라의 시민 데이터는 반드시 그 나라 안에 저장되어야 한다는 법적 규제를 충족하기 위해

리전 단위로 나누는 이유는 단순히 거리 때문만이 아니다. 각 나라마다 “데이터 주권(Data Residency)”이라는 어떤 나라의 시민 데이터는 반드시 그 나라 안에 저장되어야 한다는 법적 규제를 충족하기 위함도 있는 것이다.

이 구조 덕분에 한국 사용자는 서울 리전에서 서비스를 제공받아 지연(latency)이 최소화되고, 기업들은 법적으로 요구되는 데이터 저장 위치 규제를 지킬 수 있다.

Availability Zone은 왜 필요할까

장애를 격리하기 위해서 존재한다.
한 데이터센터(2a)에 정전이 나거나 네트워크 장애가 발생하더라도, 다른 AZ(2c, 2d)는 영향을 받지 않는다.

아래에서 설명하겠지만, Region은 물리적으로 여러개의 AZ로 구분되며
또, Region은 논리적으로 여러 VPC로 나뉘며, VPC는 여러 개의 Subnet으로 나뉜다.


우리는 VPC를 생성하고, EC2같은 인스턴스를 특정 Subnet 혹은 여러 Subnet에 띄우게 된다.
그리고 AWS에서 하나의 Subnet은 반드시 하나의 AZ에 속한다. AZ가 여러개이기 때문에, subnet-a가 존재하는 데이터센터가 사고가 나더라도 subnet-b에 존재하는 AZ는 아직 살아있다면, 내 EC2는 정상적으로 동작하게 된다.

그렇다면 다른 AZ에 있는 인스턴스가 통신할 때는 Delay가 발생하진 않을까? 걱정하지 않아도 된다.
AWS는 각 AZ끼리 전용 통신선을 깔아뒀기 때문이다. 인터넷을 경유하지 않으며, 실제로는 거의 LAN 수준(1~2ms 이하) 의 지연만 발생한다. 다만, AZ 간 트래픽에는 소량의 요금이 발생한다.

VPC (Virtual Private Cloud) 와 Subnet

Region안에서 각자 서비스마다 자신만의 VPC(Virtual Private Cloud) 를 가지게 된다.

VPC는 말 그대로 “가상 사설망” 이다. 하나의 리전 안에서 여러 사용자가 서비스를 운영하기 때문에, AWS는 각 사용자에게 독립된 네트워크 공간을 만들어주어 서로의 트래픽이 절대 섞이지 않도록 보장한다.

VPC는 내가 선택한 Region 전체에서 접근 가능하며,여러 EC2, RDS, ALB 같은 리소스들을 VPC내에 배치하게 된다 더 정확히는 인스턴스들을 VPC 내의 Subnet에 배치한다

이건 “내 네트워크 안에서 사용할 IP 주소 범위”를 뜻한다. 이 VPC는 내가 선택한 Region 전체에서 접근 가능하며,여러 EC2, RDS, ALB 같은 리소스들을 VPC내에 배치하게 된다. (더 정확히는, 인스턴스들을 VPC 내의 Subnet에 배치한다)

Subnet

VPC 하나는 수 많은 IP를 받을 수 있는 큰 네트워크다. VCP 안에서도 서브넷(Subnet) 으로 세분화하고 있다. Subnet은 단순히 네트워크를 쪼개는 것뿐 아니라, 보안 등급과 역할에 따라 분리하는 용도로도 사용된다.

VPC는 여러개의 Public Subnet과 Private Subnet으로 이뤄져있다. VPC가 사설망임에도 굳이 왜 Private Subnet이 존재하는 이유는 외부에 노출되는 면적을 최소화 하여 보안을 강화하기 위해서다.

Public Subnet

퍼블릭 서브넷은 외부 인터넷과 직접 연결 가능한 네트워크다. 이 서브넷은 Internet Gateway(IGW) 와 연결되어 있어, EC2 인스턴스가 공인 IP를 가지고 외부 트래픽을 주고받을 수 있다.

예를 들어, 로드 밸런서(ALB)나 배스천 호스트(Bastion Host)가 여기에 배치된다.

Private Subnet

프라이빗 서브넷은 외부와 직접 연결되지 않는다. 외부에서 이 서브넷 내부의 인스턴스에 직접 접근할 수 없으며, 오직 내부에서만 접근 가능하다. 하지만 내부에서 외부로 나가는 요청(예: 패키지 업데이트, API 요청)은 필요할 수 있다. 이때는 퍼블릭 서브넷에 위치한 NAT Gateway를 통해 트래픽을 외부로 전달한다.

NAT은 단방향 통신만 허용하기 때문에, 외부에서 프라이빗 서브넷으로 역으로 들어오는 것은 불가능하다. 이 구조 덕분에, “외부 노출이 필요한 자원은 퍼블릭에 두고, 민감한 자원(DB, 내부 API 등)은 프라이빗에 둔다”는보안의 원칙(최소 노출, 최소 권한) 을 실현할 수 있다.

"10.0.0.0/16" 에서 /16은 뭘까? — CIDR

VPC를 생성할 때 우리는 CIDR 블록, 예를 들어 10.0.0.0/16 같은 주소를 지정한다. 보통 VPC는 /16 만큼 네트워크를 할당받고, 그 안에서 보통 하나의 서브넷은 /24 CIDR(256개 IP)을 할당받아 사용한다.

CIDR 표기법

10.0.0.0/16, 이렇게 IP를 표기하는 것을 CIDR 표기법이라고 한다.
CIDR (Classless Inter-Domain Routing)은 IP 주소를 범위로 표현하는 방법이다.

/16 또는 /24는 앞에서부터 네트워크 영역의 비트 수를 말하며. 나머지는 호스트(사용 가능한 IP) 영역이다

IPv4의 32비트 구조에서
10.0.0.0  →  00001010.00000000.00000000.00000000
             ---네트워크 식별용---.---호스트 사용 IP---

`/16` 이라면, 이 만큼을 우리가 호스트 IP로 사용할 수 있는 것이다.
10.0.0.0  ~ 10.0.255.255

과거에는 IP를 고정된 클래스 A, B, C로 나누어 썼는데, A클래스는 /24로 1600만개를 할당받는 등 고정된 방식이라 비효율적이었다. 예를 들어 어떤 회사가 300개의 IP만 필요해도 클래스 B(65,536개)를 통째로 가져야 했다. 그래서 “필요한 만큼만 IP를 가져가자”는 철학으로 클래스 대신 CIDR 표기법이 만들어졌다.

10.0.0.0/16 은 VPC안에서 65,536개의 IP 주소(= 2^(32−16))를 사용할 수 있다는 뜻.
보통 처음(10.0.0.0)은 네트워크 주소로 쓰이고 마지막(10.0.255.255)은 브로드캐스트 주소로 예약되어 있다.